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Abstract of FR2779595 

The invention relates to a method for managing access priorities for applications with respect to the 
resources of devices that are connected by means of a communication network. The inventive method is 
characterised in that it comprises the following steps: each application is attributed an access priority with 
respect to the resources of the network, whereby said levels include at least the following levels (a) a first 
access priority for an application that does come under the direct control of the user, (b) a second access 
priority level for an application that can be directly controlled by the user, and an authorisation for a first 
application to preempt access to a resource previously obtained by a second application according to the 
respective access priorities of the first and second applications. 
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ET APPAREIL DE MISE EN OEUVRE. 

@ L'invention a pour objet un proced6 accfcs d'applica- 
tions k des ressources d'appareils connects par un r£seau 
de communication. 

Le proc£d6 est caract§ris6 en ce que ledit proc£d6 com- 
porte les 6 tapes: 

- d'attribution d*un niveau primaire de droits d'acces a 
une application effectuant la reservation d'une ressource, 

- d'attribution d'un niveau secondaire de droits d'accfcs k 
cfautres applications effectuant une reservation de ladite 
ressource, les droits cfaccfcs du niveau secondaire etant 
tels qu'Hs n'interferent pas avec les droits d'acc£s du niveau 
primaire. . 

L'invention a aussi pour objet un dispositif utilise dans la 
mise en oeuvre du proc6d§. 
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applications est mise dans une file d'attente, en attendant la liberation de 
la ressource par Tune des N applications. 

Selon un mode de realisation particulier, la mise en attente d'une 
application dans une file d'attente n'est effectuee que si cela est sp£cifie 

5 par cette application. 

Selon un mode de realisation particulier, chaque application 
possede un profil correspondant a un niveau de priorite. 

Selon un mode de realisation particulier, un des niveaux de 
priorite caracterise Une application apte a etre directement command6e par 

10 un utilisateur. 

Selon un mode de realisation particulier/ une application requiert 
le statut d'application primaire a une application primaire actuelle par un 
_proc£d£ de n£gociati_on comportant I'etape d'acceptation ou de refus du 
remplacement par I' application primaire actuelle. 

15 Selon un mode de realisation particulier, le proc£d6 de 

negociation est mis en oeuvre lorsque I' application primaire possdde le 
niveau de priorite caract6risant une application apte a etre commandee 
directement par un utilisateur et que le niveau de priority de V application 
requerant le statut d'application primaire possede un niveau de priorite 

20 identique ou plus faible. 

Selon un mode de realisation particulier, une application requiert 
le statut d'application primaire a une application primaire actuelle par un 
proc£de de preemption comportant I'etape d'abandon force dudit statut par 
1'appHcation primaire actuelle. 

25 Selon un mode de realisation particulier, le procede de 

preemption est mis en oeuvre lorsque V application requerant le statut 
d'application primaire possede un niveau de priorite plus eleve que le 
niveau de priorite de ('application primaire actuelle. 

L' invention a aussi pour objet un appareif dans un reseau de 

30 communication domestique comportant au moins une ressource locale apte 
& etre reservee par d'autres appareils connects au r6seau et des moyens 
de connexion audit r£seau, caract£ris6 en ce qu'il comporte en outre un 
gestionnaire des ressources apte & m£moriser des informations stattques 
et/ou dynamiques relatives & Tensemble des ressources locales et des 

35 applications ayant r6serv6 une ressource locale, lesdites informations 
identifiant pour chaque ressource reservee I' unique application possedant 
les droits d'acces les plus 6tendus a cette ressource. 
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D'autres caract£ristiques et avantages de rinvention apparattront 
a travers la description d un exemple de realisation non limitatif illustre par 
les figures jointes parmi lesquelles 
5 - la figure 1 est un diagramme bloc d'un reseau d'appareils 

mettant en oeuvre le procede conforme ii I'invention, 

-la figure 2 est un schema repr§sentant I'organisation logique 
d'un appareil de la figure 1. 

10 Sur les dif f erentes figures, les memes elements portent des 

references identiques. 

Le r6seau de la figure 1 est constitue dans le present exemple de 
realisation d'un bus s6rie conforme au standard IEEE 1394 -1995. Ce bus, 
reference 1, relie des appareils 2, 4, 5 et 6. On entend par 'appareil' un 

15 ensemble physiquement distinct relie au reseau. Chaque appareil peut 
comporter un ou plusieurs sous-appareils, tels que le sous-appareil 3. Ces 
sous-appareils peuvent etre des ressources, qui sont des fonctionnalites 
d'appareils Les ressources forment des modules logiciels {'software 
elements' en langue anglaise) au sens du document 'HAW mentionn6 plus 

20 loin. 

A titre d'exemple (voir figure 2), un appareil A est un d6codeur 
de television numerique, tandis qu'un autre appareil, I'appareil B, est un 
magnetoscope. Le ddcodeur A poss&de deux ressources, a savoir un tuner 
12 et un demultiplexer 13. Le magn6toscope B possede egalement deux 

25 ressources : un tuner 14 et la fonctionnalite d'enregistrement 15. Chacun 
des appareils A et B comporte une application (respectivement 18 et 19) 
qui est une interface utilisateur graphique, qui permet a un utilisateur de 
gerer directement les fonctionnalites de chaque appareil. L' interface 
utilisateur de I'appareil A permet selon le present exemple de realisation de 

30 g6rer I'enregistrement, par un autre appareil du reseau, de programmes 
issus du demultiplexer 1 3. Une ressource peut etre residente, c'est & dire 
pr6sente dds I'origine dans un appareil, mais peut egalement etre 
tetechargee. 

Chaque appareil comporte egalement un registre (respectivement 
35 reference 16, 17 pour chacun des appareil A et B). Le registre fait Tobjet 
d'une demande de brevet franpais au nom de la demanderesse, d6pos6e le 
23 avril 1998 et portant le numero 98051 10. II est d' autre part decrit dans 
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le document 'The HAVi Architecture - Specification of the Home 
Audio/Video interoperability (HAVi) Architecture' en date du 11 mai 1998 
en sa version 0.8 et mis a disposition du public depuis le 1 5 mai 1998 sur 
les sites Internet notamment des entreprises Sony, Philips, Toshiba, Sharp 

5 et Hitachi. On se r6f6rera 6galement i ces documents pour de plus amples 
renseignements sur les divers 6l6ments du r^seau, la pr6sente description 
se limitant aux elements necessaires pour I'explication de I'invention. 

Le registre d'un appareil (aussi appelg 'registre local' pour cet 
appareil, par opposition S des 'registres distants' residant dans d* autres 

10 appareils) participe a la gestion de I'ensemble des ressources de cet 
appareil. Pour cet effet, le registre comporte une table dans laquelle 
viennent s'enregistrer les autres ressources de I 1 appareil, en indiquant leurs 
attributs (type de la ressource, identificateur de la ressource dans le 
reseau, ...). Lorsqu'un module logiciel doit communiquer avec un autre 

15 module logiciel local, il peut obtenir la liste de ces modules par 
I* intermediate du registre local, qui possede une adresse locale connue. 
Lorsqu'un module logiciel doit communiquer avec un module logiciel distant 
d'un autre appareil, il peut obtenir Tadresse {'SEID') du module logiciel 
distant en passant par le registre local. Un module logiciel peut determiner 

20 une liste de modules correspondant £ certains criteres de recherche, 
independamment de la localisation de ces modules, en transmettant une 
requete au registre local qui propage cette requete aux registres distants. 
La requite comporte sous forme de param6tres les criteres de selection 
des modules logiciels recherches, par exemple le type de module 

25 (afficheur, enregistreur, ...). 

A ce titre, les ressources d'un appareil s'enregistrent egalement 
au niveau du registre local, au meme titre que les autres modules logiciels. 
Un module t6lecharg6 s'enregistre aupres du registre de I' appareil qui fait 
office de plate-forme d'ex^cution de ce module. 

30 Une application peut etre de Tun des deux profits suivants : 

Utilisateur ou Machine. Le profil Utilisateur correspond d une application 
qui interagit directement avec I'utilisateur, comme par exemple I'interface 
utilisateur graphique 18 de Tappareil A. Le profil Machine correspond & une 
application qui n'est pas contrdl6e directement par un utilisateur, mais qui 

35 met par exemple en oeuvre une action programme. Une application peut 
controler une ressource. Une application peut 6galement etre une ressource 
et £ ce titre etre control6e par une autre application. Selon le present 
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exemple de realisation, une application de profil Utilisateur aura une 
preponderance sur une application de profil Machine lorsqu'il s'agira de 
resoudre un conflit de reservation d'une ressource. On dira que le profil 
Utilisateur possede un niveau de priority plus eieve que le profil Machine. 

5 Selon une variante de realisation, d'autres profits d'applications 

sont pr^vus: Arrtere plan, Installation, Security et Syst6me, correspondant 
respectivement d des applications de faible priorite occupees k des taches 
de fond (par exemple nettoyage de donnees obsoletes), des applications 
utilisees pendant I' installation et la configuration du reseau, des 

10 applications informant I* utilisateur de certains evenements importants 
(alarmes de securite par exemple), et des applications systeme (par 
exemple les registres et les gestionnaires de ressources). 

Une ressource possede un certain nombre de proprietes : 

Une ressource peut etre de nature dite statique ou dynamique. 

15 Une ressource dynamique peut etre divis6e en plusieurs parties 
independantes, moyennant la specification de parametres adequats. 
Typiquement, la bande passante est une ressource dynamique: une 
application reservant une bande passante devra specifier la largeur de 
bande £ r6server. Une ressource de nature statique est une ressource ne 

20 pouvant etre reservee de cette maniere. 

Une ressource dynamique possedera un 6tat de reservation qui 
correspond a la quantite restante disponible. 

Une ressource statique peut etre dans un parmi trois etats de 
reservation, un etat dit disponible, un etat dit partage, et un etat dit 

25 verrouilie. Dans retat disponible, la ressource n'est controiee par aucune 
application. Dans retat partage, la ressource est controiee par au moins 
une application, mais d'autres applications peuvent neanmoins utiliser la 
ressource, avec certaines restrictions concernant les commandes de 
controle admises pour ces autres applications/ Dans retat verrouilie, la 

30 ressource est controiee par au moins une application et rejettera toute 
commande de controle en provenance d'une autre application. 

D'autre part, on associera § chaque ressource un descripteur, 
c'est a dire une structure de donnees ou encore enregistrernent, 
comportant des valeurs de variables identifiant les fonctionnalit6s de la 

35 ressource, ainsi qu'une adresse dans le reseau. Comme dej& mentionne, ce 
descripteur est enregistr£ au niveau du registre local. 
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Selon le present exemple de realisation, le descripteur de 
ressource indique le domaine d'activite de la ressource (par exemple 
audio/video, chauffage, appareils menagers, ...), le type de la ressource, 
qui indique sa fonction (syntoniseur, d6codeur, modem, ...), le niveau 
5 d 1 accessibility (ressource 'locale', accessible uniquement par des 
applications residant dans le meme appareil, ou ressource 'publique', 
accessible egalement par des applications executees sur des plates-formes 
autres que Tappareil dans lequel reside I'application publique). 

10 La gestion des ressources est basee sur un mecanisme de 

reservation. Une reservation est n6cessaire pour la mise en oeuvre de 
commandes de controle et plus generalement pour tout acces en ecriture 
changeant l etat d'une ressource. Une reservation n'est g6n6ralernent pas 
necessatre pour un acces en lecture. Une fois une reservation accept6e, 

15 r application devient une application cliente de la ressource: elle en a le 
controle, mais elle n'est pas necessairement la seule application a etre 
dans ce cas, d'ou la n6cessite d'un m6canisme de resolution de conflits 
d' acces a la ressource. 

Chaque appareil dispose d'un module logiciel appeie "gestionnaire 

20 des ressources'. Dans le reseau de la figure 2, les gestionnaires des 
ressources des appareils A et B sont references respectivement 20 et 11. 
Ces modules collaborent avec les registres. Tandis que les registres 
maintiennent localement une liste des modules logiciels (ressources, 
applications, ...) disponibles, le gestionnaire des ressources gere les 

25 informations relatives a Taccessibilite et a I'etat de ces ressources. Selon le 
present exemple de realisation, un gestionnaire de ressources gere les 
ressources locales. Les informations maintenues par les registres sont 
relativement statiques, tandis que celles maintenues par les gestionnaires 
de ressources sont susceptibles d'evoluer rapidement, d'ou la separation 

30 des deux types de services. 

Selon le present exemple de realisation, un gestionnaire de 
ressources obtient la liste des ressources locales aupr£s du registre local. 
Les ressources non r6sidentes sont ainsi facilement accessibles au 
gestionnaire de ressources. Par exemple, lorsqu'un module de controle de 

35 fonction ('FCM' selon terminologie HAVi) est d6charg6 d partir d'un 
appareil audio-video de base ('BAV selon la terminologie HAVi), ce module 
de contrdle s'enregistre aupres du registre local de Pappareil lui servant de 
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plate-forme d'exScution, tel qu'un appareil audio-video a fonctionnalit^s 
completes CFAV). 

Les principes utilises pour le reservation sont les suivants : 

- avant de lancer une commande de controle d'une ressource, 
une application doit reserver cette ressource aupres du gestionnaire des 
ressources de I'appareil dans lequel reside la ressource, et 

- une application doit liMrer une ressource qu'elle n'utilise plus. 
Selon le present exemple de realisation, une application 

souhaitant effectuer une reservation determine I'adresse du gestionnaire 
des ressources de Tappareil dans lequel reside la ressource par 
i'intermediaire du registre de Tappareil dans lequel reside I'application. Une 
fois I'adresse obtenue, '('application peut contacter le gestionnaire des 
ressources en vue de s'informer deTetat de la ressource. Le fait de passer 
par le gestionnaire des ressources au lieu de s'adresser directement & la 
ressource permet de maintenir les informations relatives a la disponibilitg 
des ressources d'un appareil de maniere centralisee au niveau de cet 
appareil. Par contre une fois la reservation obtenue, I'application ayant 
effectuee cette reservation obtient le controle de la ressource et adresse 
ses commandes de controle directement d la ressource. Le gestionnaire des 
ressources n'est contacte par la suite que pour indiquer que la ressource a 
ete lib«§r«§e. 

Pour chaque ressource, le gestionnaire des ressources maintient 
une structure de donn6es dite 'structure de contention* , qui contient les 
informations suivantes : 

(1) Informations statiques 

Ce type d'information n'a d priori pas vocation £ gvoluer. Ces 
informations sont chargees par le gestionnaire de ressources & partir des 
ressources. 

(a) Le mode de controle de la ressource 

Le mode de controle peut etre I'un des suivants: Transparent, 
Partageable, Exclusif. Dans le cas d'un controle partageable, on indiquera 
egalement le m£canisme de resolution de conflits d'acc£s partages: 
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Repartition des applications en appiication primaire e, app.ioa.ions 
secondares, ou egalite de traitemant poor toutes .as applicafons. 

(b) Nombre maximum duplications supports 

Ce champ est utiiise en cas de mode partageable ou 

,assource indigue le nombre maxima, duplications supportees 

stmultanement, le minimum etant 1 . 

(2) Informations dynamiques 

M Informations re.atives aux applications controlant <• »-"«• 
Parmi les donnees memorises relatives a cheque a P pl,cat,on. on 

trouvera : . . » 

- le profit de ('application (Utilisateur ou Mach.ne). 
. , e cas echeant, s'il s'agit d'une application pnma.re ou 

^"^/^itrttes privees. reserves * une utilisation non 

■ enC ° re d6f . ini J; champ texte comportant un descriptif du motif de la 
20 reservation (par exemple 'Enregistrement de la ChaTne Z ). 

(b) Etat actuel de la ressource: Disponible. Partage. Verrouille 

(c) Nombre duplications controlant la ressource 
25 (d) Liste des applications controlant la ressource 

(e) Liste des applications en attente de pouvoir contr6ler la 
source t» example parce <,e ,e nombre maximal duplications pour 
30 cette ressource a ixi depass4>. 

Las applications, comme .es ressources. son, identifies par une 
adresse deflnie dans le document HAVi e, portent la nom 'SEID . 

La ressource e.le-mema doit ege.ement maintenir un minimum da 
donnees reletives aux applications gui la "T^* * Z Jse 

oeuvre des mecanismes de preemption at de negoc.at.on. En cas 
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en oeuvre du mecanisme de repartition en application primaire et 
applications secondaires, il faudra memoriser au moins I'identificateur de 
Tapplication primaire. 

Dans le mode de controle Transparent, la ressource accepte un 
controle simultane sans restriction de la part de plusieurs applications, sans 
faire de distinction entre les applications. 

Dans le mode Partageable, plusieurs applications peuveht 
controler en meme temps la ressource, mais cette derni&re mettra en 
oeuvre des proc£d£s de resolution de conflit d'accfes et de partage de 
ressource si les commandes des applications risquent de conduire £ un 
fonctionnement incorrect. 

Un exemple est celui du d6codeur A de la figure 2. Le tuner de 
cet appareii est r6gle pour la reception d'un signal en provenance d'un 
transpondeur particulter, correspondant & un certain flux multiplex^. Dans 
ce flux, le demultiplexeur a la capacite de rep£rer les paquets 
correspondant a un service ou a un autre, et d'extraire ces paquets vers 
les applications clientes. En supposant qu'un flux donne v^hicule une 
dizaine de services, des applications distinctes peuvent utiliser la ressource 
demultiplexeur pour acc£der a des services identiques ou differents. Le 
demultiplexeur fonctionne alors comme un serveur. Un conflit apparaTt 
lorsqu'une application veut changer de transpondeur: ceci implique que 
toute autre application perdra Tacces aux services transmis sur le 
transpondeur actuel. 

Selon Tinvention, le proc6d6 de resolution pr6f6r6 d'un tel conflit 
est le suivant : les applications clientes d'une ressource sont classees en 
applications clientes primaires et secondaires. Une seule application peut 
etre une application primaire pour une ressource : c'est celle qui a reserve 
la ressource en premier. Toutes les autres applications sont des 
applications secondaires. La ressource accepte toutes les commandes en 
provenance de ('application primaire, mais peut n'accepter que certaines 
commandes, et ce de fa<?on Iimit6e, de la part des applications secondaires. 
Les commandes des applications secondaires ne sont prises en compte que 
dans la mesure ou elles n'entrent pas en conflit avec les commandes de 
('application primaire. Dans I'exemple du demultiplexeur donne plus haut, 
seule ('application primaire a la possibilite de changer de transpondeur. Les 
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applications secondaires ont simplement le droit de choisir un service sur le 
transpondeur actuel. 

Selon une variante de realisation, I'application primaire informe 
son utilisateur final (par exemple le tel6spectateur) des perturbations que 

5 son action peut entratner. 

Selon le present exemple de realisation, les applications 
secondaires ont toutes des possibilites de commande identiques. On 
distingue deux procedes: selon le premier procede, une application ne peut 
perturber les commandes prec6demment transmises a la ressource par une 

10 autre application f principe du respect mutuel'), tandis que selon le second 
proced^, une application peut perturber une autre application. 

Dans tous les cas, ce qu'est une 'perturbation' d'une application 
secondare par une autre, depend de la nature de la ressource contrdiee et 
c'est cette derniere qui devra trancher, Selon le present exemple de 

15 realisation, c'est le principe du respect mutuel qui est mis en oeuvre en ce 
qui concerne les conflits d'accfes entre applications secondaires. 

Selon une variante de realisation, comme deja mentionne en 
relation avec ('application primaire, une application secondaire avertit, s'il y 
a lieu, son utilisateur final des restrictions imposees a son action. 

20 Selon une autre variante de realisation, le principe d'egalite de 

traitement des applications secondaires est applique a toutes les 
applications: il n'y a pas dans ce cas d'application primaire. 

Dans le mode Exclusif, la ressource ne pourra etre contrdiee que 
par une seule application a un moment donne. La ressource memorise au 

25 moins I'identite de cette application, ainsi que son niveau de priorit6(type 
Utilisateur ou Machine selon le present exemple de realisation). A titre 
d'exemple, on prendra la commande des mecanismes d'un magnetoscope, 
comme I'appareil B de la figure 2. Un conflit peut apparaTtre si une 
application demande I'enregistrement d'une emission, tandis qu'une autre 

30 application demande un peu plus tard rejection du support 
d'enregistrement. Dans ce cas, la premiere application aura un controle 
exclusif. 

A titre d'exemple, la table 1 donne pour une ressource 
35 partageable des informations memorisees au niveau de chaque ressource : 
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Application 


Profil 


Acc6s 


Dans queue 
d'attente 


A1 


UTILISATEUR 


Primaire 


Non 


A2 


MACHINE 


Secondaire 


Non 


A3 


UTILISATEUR 


Lecture 


Oui 



















Table 1 



Selon le type de ressource, le mode de controle peut differer 
5 pour differentes comrnandes. Par exemple, seules les commandes qui 
changent I'etat d'une ressource peuvent gen6rer des conflits et justifier de 
ce fait un mode de controle exclusif ou partageable, tandis que toutes les 
autres commandes, acces en lecture, demandes d'6venements sont g6r6s 
selon le mode transparent. 

10 

Pour r^server une ressource, une application transmet une 
commande correspondante au gestionnaire des ressources local a la 
ressource. Cette commande comporte en tant que paramfetres les 
informations relatives d I'application inscrites par la suite dans la structure 

15 de contention au niveau du gestionnaire des ressources. Aucune 
reservation n'est effectuee par une application pour une ressource en mode 
transparent. Selon le present exemple, une reservation est effectu6e pour 
Tobtention immediate du controle d'une ressource. 

Selon r§tat actuel de la ressource, trois cas peuvent se 

20 presenter : 

- La reservation est accept6e et I'application devient I'application 
primaire ou une application secondaire. C'est le cas lorsque la ressource 
est initialement respectivement dans I'etat disponible ou partageable. 

• La reservation est rejet^e car la ressource est verrouill6e (par 
25 exemple parce que le nombre maximal d'applications a 6t6 atteint). 
L f application peut requ^rir, sous la forme d'un drapeau dans la commande 
de reservation, d'etre plac6e dans la queue d'attente de cette ressource, et 
d'obtenir une notification de la part du gestionnaire des ressources lorsqu'il 
lui aura automatiquement attribue un nouveau niveau d'accds (sort un 
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acces secondaire devenant primaire, soit une application dans la file 
d'attente devenant application secondaire ou primaire).. L'adresse de 
1'application est alors memorisee dans une pile de la structure de 
contention de la ressource appropriee. 
5 - La mise en attente de ('application si son profil est tel qu'il lui 

permet de negocier le titre d f application primaire avec I 'application primaire 
actuelle. Le mecanisme de negociation ou de preemption est, selon le 
present exemple, mis en oeuvre par le gestionnaire des ressources. 

Le gestionnaire des ressources transmet en retour vers 
^application le resultat de la reservation. Si la reservation est acceptee, le 
message comporte egalement reformation selon laquelle 1'application est 
primaire ou secondaire. 

Lorsque 1'application a obtenu le contrdle de la ressource et a 
termine son action, elle transmet une commande de liberation de la 
ressource au gestionnaire des ressources. Ce dernier efface alors 
1'application et les informations s'y rapportant de la structure de contention 
appropriee. 

C'est egalement le cas pour une application en attente n'ayant 
plus besoin d'une ressource pour laquelle elle a tent§ d'effectuer une 
reservation dans le passe, elle doit liberer la ressource. 

Selon le present exemple de realisation, deux m£canismes sont 
prevus pour effectuer le remplacement d'une application primaire par une 
autre application : la preemption et la negociation. Le type de mecanisme 
est identifie dans la commande de reservation envoyee par une application 
au gestionnaire des ressources. 

Lorsqu'une application souhaite n6gocier le statut d'application 
primaire avec I'actuelle application primaire, elle envoie un message en ce 
sens au gestionnaire des ressources, qui a son tour transmet un message £ 
I* application primaire. Celle-ci peut soit accepter, soit refuser de c£der sa 
place. Une application de type Utilisateur peut par exemple transmettre la 
demande d Tutilisateur lui-meme. 

Une application peut egalement mettre en oeuvre le mecanisme 
de preemption pour s'approprier le statut d'application primaire. Dans ce 
cas, le gestionnaire des ressources v^rifie que cette application a bien la 
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priorite pour faire cette requete, par rapport a la priority de 1'appltcation 
primaire actuelle. S'il autorise la preemption, le gestionnaire des ressources 
envoie une comrnande de transfert, que I'application primaire a ^obligation 
d'accepter Un temps donne est alors accorde & I'application primaire pour 
5 !ib£rer la ressource. Si ce temps n'est pas respecte, le gestionnaire des 
ressources effectue le transfert d'office de la ressource. 

En liaison avec le mecanisme de repartition des applications 
clientes en application primaire et applications secondares, la resolution 

10 des conflits pour la position d'application primaire lors de la reservation 
repond aux regies suivantes, sachant que I'on'se place dans le cas ou 
seuls les profils Utilisateur et Machine existent : 

(1) Une application de profil Utilisateur a toujours priorite sur une 
application de profil Machine. 

15 (2) La premiere application r6servant une ressource partageable 

devient I'application primaire. Une application primaire peut interferer avec 
les commandes duplications secondaires. Une application secondaire ne 
peut interferer avec une comrnande de I'application primaire. 

(3) Une application de profil Utilisateur n'est jamais soumise au 
20 droit de preemption d'une autre application (Utilisateur ou Machine) sans 

phase de n6gociation. 

(4) Quand une application primaire Iib6re une ressource, c'est 
I'application secondaire ayant le niveau de priorite le plus eiev6 qui devient 
application primaire. Dans le cas ou plusieurs applications secondaires 

25 possedent ce niveau de priorite, c'est I'application la plus ancienne qui 
devient application primaire. Une application en attente prend alors la place 
de I'application secondaire. 

Quatre cas de conflit peuvent se presenter, selon le profil de 
30 I'application primaire et celui de I'application cherchant a effectuer une 
reservation (on supposera ici qu'il y a negociation chaque fois qu'au moins 
une des deux applications est de profil Utilisateur) : 

(a) L'application primaire a un profil Utilisateur et I'application 
35 requ6rant la reservation a un profil Machine : 

Dans ce cas, la ressource transmet un message a I'application 
Utilisateur pour verifier si ce dernier peut c6der la main. Si c'est le cas. 
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l'application de profil Machine devient T application primaire. Sinon, 
('application Machine abandonne sa tentative. 

Un exemple correspondant a ce cas est celui d'un telespectateur 
regardant un service diffuse sur un transpondeur A, tandis qu'un 
5 magnetoscope pr6programm6 doit enregistrer un service sur un 
transpondeur B, utilisant le meme tuner. 

(b) L'application primaire a un profil Machine et l'application 
requerant la reservation a un profil Utilisateur : 

10 Avant de remplacer 1'application primaire Machine par 

l'application Utilisateur, le gestionnaire des ressources informe l'application 
Utilisateur des consequences potentielles de ce remplacement et lui 
demande une confirmation du remplacement, en lui donnant la possibilit6 
de laisser ^application primaire finir sa tache. 

15 Un exemple correspondant a ce cas est celui ou un 

magnetoscope enregistre un service d'un transpondeur A, tandis qu'un 
telespectateur souhaite regarder un service sur un transpondeur B, utilisant 
le meme tuner. Le telespectateur est alors averti que I'enregistrement en 
cours devra etre arrete s'il confirme sa decision. 

20 

(c) L'application primaire a un profil Utilisateur et l'application 
requerant la reservation a egalement un profil Utilisateur : 

Dans ce cas, l'application primaire d6cidera de garder ou 
d'abandonner son niveau primaire: le principe est le meme que dans le cas 
25 (a). 

Un exemple correspondant a ce cas est celui ou un premier 
telespectateur regarde un service sur un premier transpondeur (dont il a le 
controle par I'intermediaire d'une application primaire), tandis qu'un second 
telespectateur souhaite regarder un autre service d'un autre transpondeur, 
30 en utilisant le meme tuner. Le second telespectateur ne pourra r£gler le 
tuner sur la frequence du nouveau transpondeur qu'avec I'accord du 
premier telespectateur. 

(d) L'application primaire a un profil Machine et l'application 
35 requerant la reservation a un egalement un profil Machine : 



BNSDOCID: <FR 2779595A1J_> 



2779595 



15 

Etant donne que selon le present exemple, toutes les applications 
de profil Machine ont la meme priority, I'application primaire termine sa 
tache sans etre remplacee. 

5 De manidre plus generate, quand plus de deux profits existent, le 

comportement du systeme est d6crit par la table 2. Dans la variante de 
realisation comportant plus de deux profits mentionnee ci-dessus, les 
profils S6curit6 et Systeme ont d titre d'exemple des niveaux de priorite 
plus elev6s que le profil Utilisateur. II n'y a jamais de preemption d'une 

10 application de profil utilisateur par une application de niveau de s6curit6 
identique ou inferieur sans phase de negociation. Cependant, selon 
Texemple d6crit par la table 2, il n'y a pas de negociation lorsque 
('application primaire a un profil Utilisateur, mais que r application 
cherchant h obtenir le controle possfcde un niveau de priorite strictement 

15 superieur. 
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Revendications 

1. Procede de gestion de priorites d'acces d'applications a des 
5 ressources d'appareils connectes par un reseau de communication, 

caracterise en ce que ledit procede comporte les 6tapes : 

- d'attribution d'un niveau primaire de droits d'acces a une 
application effectuant la reservation d'une ressource, 

- d'attribution d'un niveau secondaire de droits d'acc6s a 
10 d'autres applications effectuant une reservation de ladite ressource, les 

droits d'acces du niveau secondaire etant tels qu'ils n'interferent pas avec 
les droits d'acc&s du niveau primaire. 

2. Proc6d6 selon la revendication 1, caracterise en ce qu'une 
ressource admet simultanement des reservations par au moins N 

15 applications, avec N supgrieur ou 6gal i 1 . 

3. Proc6de selon la revendication 2, caracterise en ce qu'une 
application effectuant une tentative de reservation d'une ressource dej& 
r£serv£e par N applications est mise dans une file d'attente, en attendant la 
liberation de la ressource par Tune des N applications. 

20 4. Procede selon Tune des revendications precedentes, 

caracterise en ce que chaque application possede le profil correspondent a 
un niveau de priorite. 

5. Procede selon la revendication 4, caracterise en ce qu'un des 
niveaux de priorite caracterise une application apte a etre directement 

25 command6e par un utilisateur. 

6. Procede selon Tune des revendications precedentes, 
caracterise en ce qu'une application requiert le statut d'application primaire 
a une application primaire actuelle par un procede de n6gociation 
comportant re tape d'acceptation ou de refus du remplacement par 

30 ('application primaire actuelle. 

7. Procede selon la revendication 6, caracterise en ce que le 
procede de negociation est mis en oeuvre lorsque ('application primaire 
possdde le niveau de priorite caract6risant une application apte & etre 
commandee directement par un utilisateur et que le niveau de priorite de 

35 I'application requ6rant le statut d'application primaire poss&de un niveau de 
priorite identique ou plus faible. 



BNSDOCID: <FR 2779595A1_I_> 



2779595 * 



17 

8. Proc6d6 selon Tune des revendications pr^cedentes, 
caracteris6 en ce qu'une application requiert le statut d'application primaire 
a une application primaire actuelle par un procdde de preemption 
comportant I'dtape d'abandon forc6 dudit statut par V application primaire 
actuelle. 

9. Procede selon la revendication 8, caracteris6 en ce que le 
proced6 de preemption est mis en oeuvre loirsque r application requerant le 
statut d'application primaire possdde un niveau de priorit6 plus 6lev6 que le 
niveau de priority de Tapplication primaire actuelle. 

10. Proc6d6 selon la revendication 3, caract6ris6 en ce que la 
mise en attente d' une application dans une file d'attente n'est effectu6e 
que si cela est sp6cifie par cette application. 

11. Appareil dans un reseau de communication domestique 
comportant au moins une ressource locale apte a etre reserv6e par d'autres 
appareils connects au reseau et des moyens de connexion audit reseau, 
caract6rise en ce quil comporte en outre un gestionnaire des ressources 
(11; 20) apte £ mSmoriser des informations statiques et/ou dynamiques 
relatives d I'ensemble des ressources locales et des applications ay ant 
reserve une ressource locale, lesdites informations identifiant pour chaque 
ressource r6servee T unique application possedant les droits d'accfes les 
plus 6tendus a cette ressource. 
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